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I. Introduction 

The analysis program (AN) is specifically designed to produce graphic and tabular information to 
aid in the design and checkout of the Center TRACON Automation System (CTAS). To best 
reveal CTAS operation and possible problems, data are plotted in many different ways both in 
detail and summary form. AN has been designed to analyze both radar surveillance data and 
output data from CTAS. AN has been extensively used to debug and refine CTAS. It is also being 
used in the field to monitor and assess CTAS performance. AN is continuously refined to keep up 
with changing needs. The present version of AN grew out of analysis of Denver Center data. 
However, the AN software has been written to be adaptable to any other facility Center or 
TRACON. Presently one can select Denver Stapleton, Denver International, Dallas/Fort Worth 
International Airport, and Dallas Love Field. 
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Different data are required for different kinds of plots. Plots that deal with radar data (position, 
speed, altitude, heading) use data generated by the Host computer in the Center, which are 
transmitted to CTAS. Some of the Arrival Sequencing Program (ASP) data are also sent to CTAS 
for comparison. The ASP, which is the present scheduling system, is implemented in the Host 
computer. Plots that deal with estimated times of arrival (ETA), scheduled times of arrival (STA), 
or actual meter fix crossing times (act_ff) use data generated by the CTAS. All data are labeled 
appropriately and stored in a file written by the CTAS Communications Manager (CM) program. 

AN produces three types of plots: (1) x/y plots, (2) time history plots, both of which use data 
directly from the file, and (3) summary plots, which are derived from the data. In addition, several 
data files are written giving statistical information about all flights, which aids in the detection of 
possible CTAS problems. The complete data file to be analyzed is read in first. During reading of 
the data file, a plan view display of the aircraft positions is shown in faster than real time, giving 
the person who analyzes the data an overview of the traffic situation. 

In Section D, the contents of the data file which CTAS records is explained. This is the only data 
file accessible to the AN program. 

In Section III, the set of graphs and numerical outputs which can be selected are briefly described. 

In Section IV, the user interface to the AN program is described. A description of input data and 
specific output data selection is given. Primarily, the Setup Display Parameter Window is 
described, which has many buttons and switches in order to select a specific graph, the ranges of 
its coordinates, and a specific subset of the data. 

In Section V, more detailed data on the operation of AN and its outputs is given. This includes 
some typical graphs, their selection, and interpretation. 

Finally, in Section VI, some summary comments are given. 

II. Input Data 

All input data to the AN program are collected in a file written by the Communications Manager 
(CM) program whenever CTAS is running. The file name is user defined at the time the 
Communications Manager program is first called. 
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The CM writes the cm-file organized in different types of records, which are listed in table 1 . The 
capitalized record ID above each sub-table is the record name, which appears as the first word of 
each record and which permits the person that analyzes the data to find specific data when needed 
for more detailed analysis. The titles of the sub-tables also give the data source and frequency of 
recording. The data source HOST is the main frame central data processor in the Center. The data 
source CTAS is CTAS itself, and the data source ASP is the present arrival sequencing system 
residing in the HOST. The data source for WTHR_STA is the National Oceanographic and 
Atmospheric Administration (NOAA). The variable ‘acid’ appears in all records which belong to 
a single aircraft, in order to identify the aircraft to which the record data belong. The data that are 
collected are listed in table 1 . 


TABLE 1 . Summary of the Records and Variables in the cm_file 


VARIABLE NAME 


EXPLANATION 


TABLE 1.1 Variables with record ID AC_DATA_F written at the radar sweep rate, every 12 sec in the Center and 5 sec in 
TRACON. Data are obtained from the HOST. 


acid 


aircraft ID eg. UAL1930 


xp 


radar x position 


yp 


radar y position 


alt 


altitude from altitude transponder 


speed 


ground speed filtered by CTAS 


heading 


vert_speed 


heading of aircraft from radar data 


vertical speed from radar 


area 


? Not used by AN 


xtime 


?Not used by AN 


raw_ground_speed 


determined by radar 


ETA_ff_condition 


estimate of good or bad CTAS ETA 















TABLE 1 .2 Variable with record ID START_TIME_F is written at the beginning of the file 


Start time 


time file is started recording 


TABLE 1.3 Variables with record ID WEATHER_STATION_F written whenever new weather data arrive 


wind_at _grid_element 


wind vs altitude and x/y position magnitude and heading 


TABLE 1 .4 Variables with record ID ADD_FLIGHT_PLAN_F written by HOST before radar track and updated as needed 


acid 

aircraft ID 

route 

filed route aircraft intends to take if not re-directed 

type 

aircraft type e.g. B727 

cf_x cf_y 

first waypoint in Center airspace coordination fix 

cf_time 

coord_fix_est_time_of _arriv al 


TABLE 1 .5 Variables with record ID DELETE_FLIGHT_PLAN_F supplied by HOST 


acid 


Not used in AN 


TABLE 1.6 Variables with record ID FREEZE_CENTER_SCHEDULE_F from CTAS event driven 


acid 

aircraft ID 

center_frozen 

center schedule is frozen (schedule not changed any more by the CTAS 
scheduler) 


TABLE 1.7 Variables with record ID ASSIGN_RUNWAY_F from CTAS event driven 


acid 

aircraft ID 

runway 

runway CTAS assumes aircraft will land on 

runway_frozen 

no more runway changes are made by CTAS 

configuration 

runway configuration ASSUMED by CTAS 


TABLE 1.8 Variables with record ID METERING_FIX_DATA_F supplied by HOST every 60 seconds 


id 

aircraft ID 

cid 

computer ID 

config 

?Not used by AN 

vertex 

runway configuration (cannot be relied upon) 

vertex_accept_rate 

airport acceptance rate 

time_of_msg 

time when message is written to the file 

fix 

ASP feeder fix 

mft 

equivalent to CTAS STA_ff also written in “TIM” 

undelayed_mft 

equivalent to CTAS ETA_ff also written in “TIM” 
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vta 

vertex time of arrival equiv to CTAS ETA not used by AN 

clt 

calculated landing time equiv. to CTAS STA not used by AN 

frozen 

ASP schedule frozen 


TABLE 1 .9 Variables with record ID TIM computed by CTAS recorded every 60 seconds 


acid 

aircraft ID 

type 

aircraft type e.g. B737 

fix 

CTAS feeder fix determined from flight plan 

Itime 

present time 

oETA 

original ETA = ETA until 5 min before freeze then constant 

ETA 

estimated time of arrival at the runway threshold 

STA 

scheduled time of arrival at the runway threshold 

oETAJf 

original ETA_ff = ETA_ff until 5 min before freeze then constant 

ETA_ff 

estimated time of arrival at the feeder fix 

STA_ff 

scheduled time of arrival at the feeder fix 

mft 

ASP equivalent to STA_fF 

undelayed_mft 

ASP equivalent to ETA_ff 

runway 

runway CTAS assumes aircraft will land on 

stream -class 

category of aircraft that can be scheduled separately to a feeder fix 


TABLE 1.10 Variables with record ID FIX: supplied by CTAS event driven 


acid 

fix_cross_cnt 

actual_gate_crossed 

actualff 

distjf 

heading_ff 

x_ff 

y"ff ~ 

speed_ff 
alt_ff " 


aircraft ID e g. UAL1930 

# times feeder fix crossed >1 if holding pattern flown 

determined from flight path 

time gate is crossed from flight path 

distance from ff when gate is crossed 

heading when gate crossed 

x position on gate crossing 

y position on gate crossing 

ground speed on gate crossing 

altitude on gate crossing 


Although most CTAS data are recorded every 60 seconds, actually they may be computed much 
more frequently. Some of the recorded variables are not used by AN, but all are listed above, since 
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they may be used at a later date. For example, the only variables presently used by AN that are 
recorded under record ID ‘FIX:’ are ‘acid’ and ‘actualff’. 


III. The Output 

The output consists of well annotated graphs which must be selected as well as detailed summary 
printouts and printouts of questionable data which are written automatically. The graphs present 
the data in different ways in order to check for the correct operation of CTAS and to permit the 
visual spotting of possible problems. 

III.l The Set of Graphs. Similar graphs can be selected to present similar information for either 
the new system (CTAS) or the existing system (ASP). In addition, table 2 lists two graphs 
(ETA_ff & u_MFT - act_ff vs act_ff and ETA & MFT - act_ff vs act_ff) which were especially 
designed for making direct comparisons between the two systems on a single graph. 


table 2. Brief Description of the Set of Graphs and its Uses 


GRAPH SELECTED 
X/Y 


SHORT DES CRIPTION FOR USE OF THE DIFFERENT PLOTS 

Determine traffic situation: Delay maneuvers, landing patterns. Abnormal missing data, 
trajectory jumps, that actually belong to two different aircraft with the same computer 


Altitude vs time 


ID 

1) Aircraft may be separated by 


stream classes, aircraft types, and/or feeder fix. 


Ground speed vs time 


Heading vs time 


2)Check out individual altitude profiles 

Original raw ground speed had many large jumps, causing ETA jumps and schedule 
problems. Now, speed is heavily filtered, still look for abnormal speed profiles 
Determine landing directions vs. time for low altitude only. Closest to actual 
information of runway use vs. time. This does not distinguish between left and right 


Vertical speed vs time 
Radar coverage vs time 
Feeder fix throughput vs time 


runway 


Shows overall traffic density 

Aircraft flying across a feeder fix are counted in 1/2 hour sliding intervals which are 
moved in 10 minute steps. Actual crossing times at each feeder fix are shown at bottom 


Distance from airport vs time 
Landing throughput vs time 


of the graph. 

Useful for ATC study when steamclass is selected 

Aircraft landing/hour counted in 1/2 hour sliding intervals which are moved in 10 min 
steps. Actual landing times (times of last radar hit) are shown at bottom of graph 

















TABLE 2. 


Brief Description of the Set of Graphs and its Uses 


GRAPH SELECTED SHORT DESCRIPTION FOR USE OF THE D IFFERENT PLOTS 

ETA_ff - act_ff vs act_ff * At low density traffic the values ETA_ff - act_ff vs act_ff should be close to zero and 

centered around zero. For high density, they should be positive. 

STA_ff - act_ff vs act_ff * If traffic is controlled by CTAS, the values STA_ff - act_ff vs act Jf should all be close 

to zero. 

u_MFT * act_ff vs act_ff* ASP equivalent of ETAJY - act_ff vs act_ff 

MFT - act_ff vs act_ff* ASP equivalent of STA_ff - act_ff vs act__ff 

ETA_ff & u_MFT - act_ff vs Direct companson between CTAS and ASP data 

act_ff* 

STA_ff & MFT - act_ff vs Direct comparison between CTAS and ASP data 

act_ff* 

ETA_ff vs time Check that ETA_ff curves are reasonably smooth. Make more checks for those curves 

that are not. Note that ETA_ff curves often intersect and the influence on the schedules 

(STA_ff). ETA_ff before the aircraft is tracke d by radar is based on the flight plan 

STA_ff vs time Observe that the aircraft in each stream class have proper separation at the feeder fixes. 

Only the data points count. Vectors identify curves. 

ETA vs time Check that ETA curves are reasonably smooth. Make more checks for those curves that 

are not. Note that ETA curves often intersect and the influence on the schedules (STA) 
STA vs time Observe that the aircraft have proper separations at the runway thresholds. Only the 

data points count. Vectors identify curves. 

OETA vs time OETA should almost be the same as ETA (except for spikes in ETA) and be frozen 5 

min before freezing ETA. 

OETA_ff vs time OETA ff should almost be the same as ETA_FF (except for spikes in ETA FF) and be 

frozen 5 min before freezing ETA_FF. 

undelayed MFT vs time Compare ASP data with CTAS ETA_FF — = 

MFT vs time Compare ASP data with CTAS STA_FF 

ETA &STA vs time Observe details of scheduling to threshold. Usually a few select curves. 

ETA_ff & STA_ff vs time Observe details of scheduling to feeder fix. Usually a few select curves 

STA - ETA vs time Presently, plotting is stopped at freeze horizon. The values should rarely be negative 

unless time advance is on. When CTAS is used to control the traffic. STA - ETA should 
go to zero past the freeze horizon as the runway threshold is approached. 

STA _ff - ETA_ff vs time Presently, plotting is stopped at freeze horizon. The values should rarely be negative 

unless Time Advance is on. When CTAS controls STA_ff - ETA_ff should go to zero 
past the freeze horizon as feeder fix is approached. 

etaff,staff,actff snapshot shows schedules to each feeder fix at a specific time 

OETA.ETA.STA snapshot shows schedules to each runway threshold at a specific time 

Scheduled delay = Sum (STA - Compare different scheduling algorithms for their effect on scheduled delays 

ETA) & # aircraft scheduled 































table 2. Brief Description of the Set of Graphs and its Uses 


GRAPH SELECTED 

SHORT DESCRIPTION FOR USE OF THE DIFFERENT PLOTS 

Average delays vs time 

While running pre-recorded data, compare different scheduling algorithms for their 
effect on scheduled delays 

ETA^ff order_deviation** vs 

This tests how well the CTAS ETA_ff order corresponds to the actual order crossing the 

actff 

feeder fixes. 

STA_ff order_deviation** vs 

This tests how well the CTAS STA_ff order corresponds to the actual order crossing the 

actff 

feeder fixes. 

undelayed_MFT 
order_deviation** vs actff 

For comparison of CTAS vs ASP undelayed arrival time calculations 

MFT order_deviation** vs actff 

For comparison of ASP schedules vs actual ff crossings when ASP has control 

ETA_ff statistics 

Alphanumeric summary output of ETA_ff errors compared to act_ff crossing. 

STA_ff statistics 

Alphanumeric summary output of STA_ff errors compared to act_ff crossing. 

undelayed MFT statistics 

Alphanumeric summary output of undelayed MFT errors compared to act Jf crossing. 

MFT statistics 

Alphanumeric summary output of MFT errors compared to act^ff crossing. 

Comb ETA STA Runway 

ETA, STA for the selected time is plotted for each CTAS assumed runway in form of a 

direction*** 

comb diagram. 

Comb ETA_ff, STA Jf, STA 

ETA_ff, STAJf, STA. Special comb diagram to check ordering 

Runway direction*** 


Comb ASP*** 

undelayed_mft, mft, actff comb diagram for the existing system 

Comb CTAS*** 

ETA_ff, STA__ff, actff comb diagram for the CTAS system 


’Feeder fix crossing time is cslcul&ted for tfie octudl ff. NVhen CTAS assumes 3 different feeder fix, the ETA_ff will be lsrge After 
the actual feeder fix has been crossed 


** All order deviations are deviations from the actual order of arrival at the feeder fixes, (e.g. order of ETA_ff vs of actual order of 
arrival at the feeder fixes. 

*** Comb diagrams have been used to explain scheduling and delays in Neuman. F.; and Erzberger, H.: Analysis of Delay 
Reducing and Fuel Saving Sequencing and Spacing Algorithms for Arrival Traffic. NASA TM-103880, October 1991. 

The specific output depends on a number of control settings which will be discussed after 
describing the display setup windows. 

III.2 The Plot Header. The plot header consists of one line white on black text defining the 
graph. It contains the version name of the program, the file identification that is plotted, the time 
range of the data, and a list of the data filters in use. The first element of the plot header is the 
name of the program ‘AN_1 l_5_93’with the date of the version. Next the storage location and 
name of the file from which the data was plotted is specified. This is followed by several 
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indications on the state of the selection buttons. Only selections that are meaningful for the given 
plot and which are not ignored by AN will be displayed. These will be explained when describing 
the function of the buttons. Next the start and stop times (in local time) of the recorded file are 
given. When data are produced while CTAS is in the replay mode, the actual times depend on the 
times the file is replayed to obtain a new cm file while using different CTAS scheduling 
parameters. So that different replays can be easily compared, the start time for time plots has been 
normalized to zero. 

111.3 The statistics printout. The statistics printout for each aircraft in the file is derived from the 
cm data. The one line printout for each aircraft contains the aircraft ID, aircraft type, time of 
initial radar coverage, the time between first and last radar track, the length of the trajectory as the 
crow flies from the first radar hit to the airport, the x and y position of the coordination fix, the 
difference in distances to the airport of the first radar hit and the coordination fix. (A positive 
number means that the aircraft was tracked before flying over the coordination fix) In addition, the 
printout contains the route, as given in the flight plan, the time the feeder fix was flown over, the 
altitude the feeder fix was flown over, the feeder fix gate assumed by CTAS, and the actual feeder 
gate the aircraft flew over. As a measure of the quality of the data, a count is reported of the 
number of times all aircraft data have been removed at a specific time because of at least one 
value being out of range. Example of a file name is: statistics_for_cm_0818_2 

111.4 The jump files and other analysis files. The analysis system looks for questionable jumps 
in the data by comparing adjacent data points, and it writes files recording such events. These files 
can be used to spot possible errors in the system. The aircraft data with suspicious data points can 
be plotted separately. If desired, the files are automatically labeled and stored with a name that 
identifies the name of the file from which the data originated as well as the types of jumps that are 
recorded. These files all start with a ‘j ’ for easy deletion after the desired information is 
abstracted. The following files are written: 

j_acceptance_rate: This file records changes of ASP acceptance rate including the time of change 
as well as ASP runway configuration (vertex) changes. These values are also printed out in the 
plots where time is the abscissa. Example file:j_acceptance_rate_for_cm_0818_2 

jumps_alt: This file records the times when altitudes change between radar updates that are larger 
than can be expected. An output is recorded when the change in altitude [in units of 100 ft] 
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divided by the time between samples [in seconds] is greater than 2, provided the samples are not 
in the TRACON area. Example file: jumps_alt_for_cm_0818_12 

jumps_speed: This file records the times when large speed changes occur between radar updates 
for each aircraft. An output is recorded when the flight is past the initial portion and not close to 
the TRACON and when the speed jump per second greater than 5 knots/sec. Example file: 
jumps_spd_for_cm_08 1 8_ 1 2 

jumps_xy: This file records position and time span information when there are intervals of no 
radar data for a specific aircraft. Two types of errors can be identified. (1) No radar returns for a 
short time for a specific aircraft. (2) Large jumps in x/y position and often in time, which means 
that two different aircraft had the same CID (computer id). An output is recorded when either the 
change in x or the change in y is more than 10 miles for adjacent data samples. Example file: 
jumps_xy_for_cm_08 1 8_ 1 3 

jumps_ETA_ff_STA_ff: Records suspiciously large changes in ETA_ff, STA_ff, ETA or STA. An 
output is recorded when any quantity changes by more than 5 minutes between adjacent samples, 
which are 1 minute apart. Example: jumps_ETA_ff_STA_ff_for_cm_0818_2 

jump_debug: Special purpose file that may be changed as warranted. Example file: 
jump_debug for cm 08 1 8_ 1 2 

j_weather: The wind data read from the cm file are recorded in an easily readable format. 
Example file: j_weather_for_cm_0818_12 

HI-5 Schedule Snapshots for Schedule Validation. From the STA and STA_ff versus time plots, 
one can visually estimate if all separations are properly scheduled. However, this is not an 
accurate measurement, and, due to many crossings of the curves, it is a difficult undertaking. 
However, each individual schedule, computed for a specific time, must conform to all the 
constraints. The STA_ff must be properly spaced at each feeder fix for each stream class, and the 
STAs must be properly spaced for each CTAS assigned runway. The thresholds are 1 minute 
separation at the feeder fix for each stream class, and the approximate thresholds are given in table 
3 for the time separations at the runways. The actual separation thresholds vary for several 
reasons, including changing winds. For this reason the information of the aircraft separation 
matrix has to be included at the beginning of each file and whenever it changes. (This is presently 
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not the case.) Therefore, we plot the schedule information for a specific set of TIM time stamped 
data, which contain the ETA, STA, ETA_ff, STA_ff. For greater familiarity, the display is 
contracted using vertical timelines similar to TMA for each runway and feeder fix. Otherwise it is 
similar to the comb diagrams, except turned 90 degrees. The above described program will not 
only check if the schedule follows these separation restrictions but also shows all position shifts, 
and it indicates for each aircraft the type Get, turbo, or prop), the weight class (heavy, large, or 
small), the freeze status, and whether the aircraft is tracked by radar or scheduled from flight plan 
information only. 


table 3. Separation Matrix for Aircraft Landing (IN SEC. and N.MI.) 




SECOND 

TO 

LAND 



heavy 

large 

small 

FIRST 

heavy 

85s /4mi. 

116s / 5mi. 

138s/6mi 

TO 

large 

54s / 3 mi. 

65s / 3mi. 

88s /4mi. 

LAND 

small 

51s/3mi. 

62s / 3mi. 

65s / 3mi. 


IV. The Display Setup Windows 

The Display Setup Windows have pull-down menus, selection buttons, and sliders, which are 
required for the efficient analysis of CTAS data especially of the stream class schedules to the 
feeder fixes and the schedules to the runway thresholds. The meaning of these elements will be 
discussed subsequently. 

IV.l The Data Analysis Pull-Down Window. To bring up the data analysis pull-down menu, 
shown in figure 1, right-click anywhere on the plot. Right-click on a menu choice to select it. The 
first option in the pull-down menu. Frame, brings up the standard Sunview window menu 
allowing one to close, move, resize, move to front or back, re-display or quit the window. Toggle 
Setup makes the setup display parameter window appear and disappear, and Toggle Label 
allows one to turn graph labels on and off. Plot sends the current screen graph to the laser printer. 
Quit exits the data analysis tools. (One will be asked twice to confirm that the data analysis is to 
be shut down.) 


Frame =*> 
Toggle Setup 
Toggle Label 
Quit 
Plot 


Figure 1 . The Data Analysis Pull-Down Window. 

To bring up the setup display parameter window, either 

• left-click anywhere on the plot, or 

• right-click anywhere on the plot to bring up the pull-down menu 
shown in figure 2.1, then right-click on Toggle Setup. 

IV.2 The Setup Display Parameter Window. This window, shown in figure 2.1, is the main 
window to select data files, plot diagrams, plot scales, and data sub-sets. There are keyboard entry 
points and push buttons to select a function, as well as twelve rotary buttons that can be operated 
in two different ways. Using the left mouse button, adjacent choices will be displayed. Using the 
right mouse button all choices for the particular button are displayed in a window, and a choice 
can be made by moving the cursor over the desired value. In addition, there are sliders to select 
plot scales. 
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[ READ ] Directory: . 

File Name: upl_0l21_10 

l plot ] AC ID loci: 

AC ID Excl : 

[ PRINT ] AC Mode- In/ -Ex: 


HIDE ] 
STOP ] 


Del 


•* Plot ** 
Actl v AC*>: 
Time tD FF 
Curve T yp« 
Show ACID' ; 
ETA/RVY Inf 
Airport: 


G K/Y 

G All 

Gf«2 TIM 
G Vectar 
NO 

G None 


Gd tes : 

AC Class: 
AC Type: 
Runway : 
Stream : 


GDENVEH STAPLETON 


G A 1 1 
Cam 
Gad 

0 All 

G All 


ScalefWVin] [50] 

S ■ 

X-Of fset[p1x] [570] 

1 

Y-Of fset(pixj [438] 

0 ■ 

Tlme0[h*10,UTC] [0] 

»l 

DT ime[h* 10] [96] 

0| 

Qrd Offset T Ime [0] 


Ord Interv[m1n] [0] 

°[ 


] 1141 



□ 240 


□ 120 


Figure 2.1. The Setup Display Parameter Window. 

IV.2.1 File and Airport Selection. The directory must be specified with respect to the relative 
position that the data file resides in with respect to where the AN program resides. For example, if 
the AN program resides at the same file level as the data, and the data are stored in a directory 
called ‘cm_tm’ then ‘Di rectory :../cm_tm/’ will be the proper command, and under ‘File Name:’ 
the name of the file must be entered. 

The Airport: button is used only once before or after the file is read in. The button selects the 
appropriate airport. Besides centering the data around the selected airport in the x/y plot, it also 
sets up the correct feeder fixes for the Gates: button, runway choices for the Runway: button, and 
stream classes for the Stream: button. Presently the AN program is adapted for Denver Stapleton, 
Denver International, Dallas-Fort Worth, and Dallas-Love Field. 

IV.2.2 The Primary Toggle Buttons. The control panel has six primary toggle buttons: READ, 
PLOT, PRINT, HIDE, STOP, and QUIT. 

The READ button initiates the reading of the file after it is specified by directory and file name. If 
a file is incorrectly specified, a message is displayed: “File not found”. During the reading of the 
data, a faster-than-real-time plan- view display of the traffic is presented, along with a message 
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‘Reading input file - Please wait. In addition the UNIVERSAL time and the cm time are 
displayed. The cm-time shows the amount of time the cm has been recording data. The reading 
might be stopped temporarily by pressing the right mouse button. This action brings up a small 
window where one of the choices is ‘print’. Thus one can plot the horizontal traffic situation at 
any chosen time. When all data have been read in, the earlier message is replaced by ‘Done! 
Please proceed’. 

The PLOT button initiates plotting the data after all control buttons have been properly set. If 
PLOT is selected before any data have been read in, a warning message ‘Read file in first’ is 
displayed. The window of the **Plot** rotary button is shown in figure 2.2. It has a different 
function from the PLOT button and serves to select specific graphs. 


Please prociid 


TH 

'•TAJ 


OTC-TIME = 17:12 


CM-TIME = 02:59 


[ READ 1 Directory: 
File Name : 


- */cm, 

i_o: 


[ PLOT 1 AC ID Incl : 

AC 10 Excl : 

[ PRINT] AC Model ln/-Ex 
«* Plot ** : C 


[ HIDE ) Activ AtT 7 : 
Time to FF 
[ STOP I Curve T ype 
Show ACID'' 


[ QUIT ] ETA/RVY Inf?: G 
Airport: ^ 

Seal e[!*4/ in] [50] 2 

X-Offset[pix] [570] 
Y-0ffset[p1x] [438] 
TimeO[h*lQ,UTC] [0] 

DT ime[h*10] [30] 

Ord Offset Time [0] 

Ord Interv[m1n] [0] 




'TAftUM 


' mhactim 

' H«L Lt 73 


,tm/ 


Altitude vs time 

Speed vs time 

Heading vs time 

Vertical Spaed vs time 

Radar Coverage vs time 

Feeder Fix Throughput vs time 

Landing Throughput vs time 

ETAFF - actFF vs act 

STAFF - actFF vs act 

U_MFT - actFF vs act 

MFT - actFF vs act 

ETAFF & LLMFT - actFF vs act 

STAFF a MFT - actFF vs act 

ETAFF vs time 

STAFF vs time 

ETA vs time 

STA vs time 

0ETA vs time 

0ETAFF vs time 

Undelayed MFT vs time 
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Figure 2.2. Setup Display Parameter Window with PLOT with right mouse button and x/y checked. 
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The PRINT button will initiate a screendump of the screen image to the printer while at the same 
time hiding the control panel. If the PRINT button is pushed twice before plotting a new graph, a 
message appears asking if one wants to print the same graph again. This prevents time- and paper- 
wasting inadvertent multiple copies of the same graph. The control panel will reappear on its own 
eventually or upon pressing the left mouse button. 

When pressed, the HIDE button hides the control panel from view. Clicking the left mouse button 
while the cursor is in the image window will bring the control panel back into view. On rare 
occasions the HIDE button does not respond. Putting the cursor on the upper rim of the main 
window and pressing the right mouse button will bring up a small window. If one selects ‘front’, 
the main window will go to the front and the control panel will vanish. 

The STOP button stops reading the data to be analyzed to give the user an option to analyze only 
a portion of the data. How much of the file has been read so far can be seen by reading the cm 
time displayed on top of the display. 

The QUIT button permits the user to quit the AN program. Since it wastes time to accidentally 
quit the program, the user will be asked if he really wants to quit. 

IV.2.3 The Scale Selection Sliders. The window shown in figure 2.1 has seven sliders. The top 
three sliders apply only to the x/y plot. The Scale slider adjusts the screen scale in nautical miles 
per inch. The next two sliders are originally adjusted so that the center of the selected airport is at 
the center of the screen, marked by two crosshair axes and concentric circles. With the next two 
sliders the origin of the airport map can be moved anywhere on the screen, and the coordinate 
system will move with it. 

For time plots, the fourth and fifth sliders from the top adjust the start point and the time interval 
of the abscissa. The last two sliders determine the time origin and time interval of the ordinate, 
where the start time can be varied over 24 hours and the interval over 2 hours. When the last two 
sliders are set to zero, the ordinate has the same scale as the abscissa. 

IV.2.4 The Data Filter Buttons. It often happens that one wants to select data for several specific 
aircraft on the same plot. Several buttons have this purpose. Several other buttons are used to 
analyze the ETAs and the scheduling both to the feeder fixes and to the runway threshold. 
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The first button is an ‘AC ID Inch’ button. The button can select a single aircraft such as 
UAL255 or a single group of aircraft such as UAL. Also, a number of aircraft IDs can be entered 
sequentially with or without a break. (Presently, multiple groups such as AAL and UAL cannot be 
selected.) To select a larger number of aircraft the control window can be stretched. 

Another button has the opposite function of the ‘AC ID Inch’ button. If one wanted to print data 
for all aircraft except a given group, the aircraft IDs of the aircraft to be excluded would be 
entered after ‘AC ID Excl:’. Again a number of specific aircraft can be entered here, or the name 
of a single class such as ‘UAL’. 

If one wanted to include specific aircraft types only, one would list the type(s) under AC Model 
In/Ex:. Without a prefix (e.g. B747) only data for B747s will be plotted. By putting a minus sign 
in front of the type (e.g., -B727), the program will exclude plotting aircraft information for that 
type. 

The three include/exclude buttons work in conjunction. That is, one can include all UAL aircraft, 
except UAL1235, and also exclude all aircraft of type B727. Since this button selects very 
specific aircraft types out of a list of over 200 types, it is presently seldom used in favor of two 
buttons, which will be described later. 

The following bug remains in the above selection program. If, for example, UAL1236 is selected 
and UAL123 exists, it also will be plotted. This is of little consequence, since this rarely happens. 
Also the curves can be automatically labeled, so that there is no mistaken identity. 

The Gates button selects one or all of the feeder fixes determined by CTAS based on the filed 
flight plan: e.g., DRAKO, KEANN, KIOWA, and BYSON for Denver Stapleton. The labeling on 
the top line of the graph then reads FF = All FF or FF = DRAKO, etc. If, for instance, one plots 
X/Y plots for all jets that CTAS assumes will go through feeder fix DRAKO and one finds some 
of the aircraft actually fly over another feeder fix, one can investigate why CTAS assumed 
another feeder fix than the actual one. For the Denver Stapleton airport this type of check has 
removed virtually all incorrect interpretations of the flight plan as far as feeder fixes are 
concerned, and it will be useful when adapting CTAS to other airports. 

The AC type button selects: jet, turboprop, prop, or turboprop and prop, and the AC class selects: 
heavy, large, or small aircraft. 
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The Stream: button separates aircraft by the CTAS assigned stream class, which is recorded in 
the last word of each TIM message. The same set of aircraft could also be selected by choosing a 
feeder fix and an aircraft class. This fact can be used as a check on CTAS. In order to check the 
validity of the schedules produced by CTAS, the STA_ff data need to be separated by stream class 
and the STA data by CTAS assigned runways. Again these selection buttons operate in 
conjunction. Type and class are determined via table lookup from the flightplan file aircraft type 
(e.g., B727 results in large jet). When all types or all aircraft classes are selected, there is no 
output on the header line. Otherwise the chosen type is listed after “Type =” and the chosen 
aircraft class after “AC =”. 

With the Runway button, one can select any of the runways for the selected airport. The choice is 
indicated in the header line as “Runway =”. If one selects another airport, the runways that can be 
selected will change automatically. The Runway button selects runways chosen by CTAS not 
runways that aircraft actually landed on. 

IV.2.5 The Curve Format and Labeling Selection Buttons. Several buttons are dedicated to draw 
different styles of curves and data points. Often many curves are drawn which need to be labeled. 
Several styles of labeling exist. 

All recorded data consist of individual data points. Often it is easier to envision them as 
representing complete curves. However, as will be shown later, it is sometimes required to show 
the individual data points. The ‘Curve Type’ button permits these variations (table 4). 


TABLE 4. The Curve Type button 


Heading 

Meaning 

sml points 

Only data points are shown as single pixel 

lrgpts 

Each data point is shown as solid square using 9 pixels 

\fector 

All data point are connected with thin lines. Individual points not visible. 

v &pts 

9 pixel square data points are connected with lines of single pixel width 

5th pts 

Single pixels every 5th data point 9 pixel square every 50th data point. This is especially useful for x/y 
plots, where point separations indicate speeds. 
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Another button is Show ACID, which provides various ways of labeling the plotted curves 
(table 5).: 

table 5. The Aircraft ID labeling button 


Heading 

Meaning 

No 

Curves are not labeled 

Top/Side 

For X/Y curves a/c IDs are listed in the quadrant of origin. All other curves are labeled at the top of the 
graph at beginning of the curve 

On track 

Curves are labeled at the end of each curve 


When the curves are labeled ‘On Track’ more information than the Aircraft ID is given. The first 
element is aircraft ID. The second element is aircraft type. The third element is actual feeder fix 
crossing time-plotted variable (e.g., ETA_ff). The fourth element is the actual gate crossed (e.g., 
NW = 0, NE = 1, SW = 2, SE = 3 for Denver Stapleton), and the fifth element is the CTAS 
assumed gate, which is printed only if the actual gate and CTAS gate are different. 

The next button determines which information is plotted on the curves at the time a certain event 
occurs (table 6). Each type of information is selected separately, since, otherwise, the information 
on the curves would be cluttered. The choices are: 


TABLE 6. ETA/RNWY/TFF information 


Heading 

Meaning 

None 

No additional information 

ETA info 

Numbers are added to the curves at the start of each event change (see below) 

RWY info 

Runway numbers are added to curves, at the point of change, e.g. durmg scheduling or gate balancing. 

IFF info 

Time to feeder fix. Times where ETA_ff estimates a certain time to a feeder fix, and ETA_ff, STA_ff 
etc. are collected for further plotting 


when ‘ETA Info’ is selected with the ETA/RNY Inf button, numbers are plotted on the curves 
which represent messages about the validity of the ETA. Here is a summary of what the 
ETA_condition flags indicate: 






-1 = This indicates that the ‘ts’ encountered an error so that no ETA could be generated. 


0 = The aircraft has just been added; therefore, there has not been time for an ETA to be 
generated. 

1 = If check_ts_reply_valid returns true (no “ts” errors) this by itself does not necessarily mean 
that an ETA has been generated, only that there was no error encountered in the ‘ts’. 

2 = if the ‘ts’ does not send any ETA information by the time aircraft information is printed, a 
counter is advanced. If after six print cycles (about 72 seconds) no ETA info is sent, this flag is 
set, and remains set until any ETA information is received. 

3 = time check between the Da_to_pvd and Pvd_to_da_header is performed. If this fails, then the 
ETA is bad. 

9 = If the aircraft was new and is now active but the ‘ra’ has not yet received a heading, no ETA 
can be generated. 


When a specific Runway is selected and RWY info is also selected, runway information is not 
plotted on the curves, since it is superfluous information. (The runway is specified in the black 
header line of the graph.) 

The Time to FF button recalls specific values stored in a structure based on a search over a small 
interval around the specified times of 0 minutes, 19 minutes, and 30 minutes, as well as at the 
freeze horizon. Based on the first value of ETA_ff or undelayed_mft, respectively, that falls into 
the interval, during reading in of the data from the ‘cm’ file, the program stores ETA, ETA_ff, 
STA, STA_ff, undelayed_mft and mft for future plotting. The printouts for these cases on the 
header line of the graph are ‘0 min to FF’, ‘ 19 min to FF’, ‘30 min to FF’, or ‘Freez to FF’. 

Not all controls are active for each graph. The active ones are labeled x, X, or Y in the following 
table. In most instances the buttons are not active where they would not be useful. 
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In table 7, x or X mean that the button is active (will influence the plotted data), while 0 means 
that the button is inactive for the specified graph. X means selecting ‘on track’ labels points with 
errors greater than +/- 2 minutes and ‘top/side’ labels points greater than +/- 4 minutes. 

Y means selecting ‘on track’ labels end points of the comb diagram with aircraft IDs and selecting 
‘top/side’ labels end points of the comb diagram with aircraft models (e.g., B737). 


TABLE 7. The Set of Buttons that Work on Each Graph 
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V. Detailed Outputs of the Analysis Program 

First, a number of graphs will be shown, which give some insight into the data. For some of these 
figures the process of selection has been used in order to show the data of interest. How this is 
done will be described next. When CTAS was run with live data, a specific runway configuration 
and the scheduler parameters had to be selected, which did not necessarily agree with the actual 
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runway configuration. Rerunning the data gives the experimenter the opportunity to set the 
previously unknown runway configuration to the proper value and/or to adjust the scheduler 
parameters for hopefully improved results. Finally, the AN program cannot possibly cover the 
analysis of all situations. For a new situation, it is often best to write a small C-script program to 
examine the problem numerically before programming a new graph. C-script programs are also 
useful to check the accuracy of the graphs. 

V.l Example Plots with Comments and Plot Interpretation. A number of plots showing 
recorded live data will be presented and discussed. The data shown are mostly for Denver 
Stapleton. While problems are often pointed out, one must not get the impression that there are 
nothing but problems. However, AN is designed to detect problems. In this text the figures are 
smaller than those on the screen (14.5 x 11 in.) and also smaller than the printed version 
(11 x 8.5 in.). 

Figure 3 shows the control window in the upper right corner. 

While the data are read in, a plan view display of the aircraft positions is shown. By selecting 
HIDE the control window disappears and one can observe all incoming traffic in faster than real 
time. By pressing the right mouse button, the reading of the data is stopped and the small window 
in the left lower quadrant appears. By selecting PRINT one can make a hard copy of interesting 
traffic situations after hiding the setup display window. Since the recording time is shown on top 
of the display, the printed horizontal situation can be correlated with other data on the cm file. 
Close to the top of the display area UTC-time and Cm_time are shown. The Cm-time indicates 
how many hours of data have been read this far. This can be used to stop further reading of data 
when the complete file is not of interest. 

The x/y plot of a two hour incoming Denver Center traffic sample is shown in figure 4. This 
shows a typical traffic pattern in a two hour period which includes a minor rush. Nearly all the 
traffic enters the TRACON via four feeder gates. Two of them, DRAKO and BYSON, are shown 
as small squares in figure 4 just inside the 50 mile circles. The **’ with aircraft ID are the 
coordination fixes. This is part of a study to find if coordination fixes usually occur before or after 
radar tracking. The coordination fix is the position the aircraft is trying to fly over when entering 
the Center airspace. In the flight plan and subsequent updates, there is also a predicted time for the 
coordination fix crossing, which is used for long term scheduling before radar data are received. 
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In the statistics file the differences in distances between first radar hit and the airport and 
coordination fix and the airport are given. 

Several delay trajectories can be seen, especially in the SE quadrant. In addition, there was some 
gate balancing activity initiated by the TMU where an aircraft’s gate was changed from the one 
specified in the flight plan. In the data file, gate balancing is presently detected by changes of the 
ASP gate sent from the HOST computer. Presently CTAS is more often correct in its gate 
assignment than ASP. Hence ASP gate assignment is considered by CTAS scheduling only when 
the ASP gate changes in mid flight. 
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Figure 4. x/y plot of aircraft tracks for live traffic into Denver. 


Figure 5 shows the final heading angles of landing aircraft. It can be seen that about an hour after 
starting the file, the runways were changed from 26L/26R to 8L/8R. This runway change 
information vs. time is not available on the x/y plots. Since CTAS is presently not yet used to 
control the traffic, but is used in a test run mode, where it only calculates ETAs and STAs, 

CTAS presently does not pay any attention to such runway changes and simply calculates 
expected arrival times and schedules to CTAS assumed runways, while in dense traffic ASP is 
used to control it. 

From figure 5, 5 minutes after the runway change was entered aircraft still landed on 26L and 
26R. Only then began aircraft to land in the opposite direction. The ASP airport acceptance rate 
began with 88 aircraft per hour. After less than 1 hour this was reduced to 64 aircraft per hour. At 
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Figure 5. Final heading of landing aircraft into Denver Stapleton. 
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that time the vertex was changed from 4 to 8, which means that the runways were changed from 
26L 26R to 8L 8R. As time went on, the airport acceptance rate was further reduced from 64 to 56 
and then to 45. 

Several straight lines, which cannot be flightpaths, can be seen in figure 4. Either from the 
jump_xy file or by reducing the number of flightpaths via the control buttons, the odd trajectories 
can be identified.These are shown isolated in figure 6. Data points are shown as heavy dots 
connected by thin lines. It is obvious that the separate trajectories do not come from the same 
aircraft. This is further proven by the vertical profiles for the two aircraft shown in figure 7. In this 
case only data points are shown. The higher altitude aircraft COA791 has more than 10 minutes 
data gap between the correct aircraft and another aircraft, which happened to have the same 
computer ID (but not the same aircraft ID). The lower flying aircraft has a much smaller data gap. 
But, again, the data before and after the xyz jump do not belong to the same aircraft. The CTAS 
system has to work in spite of these occasional input errors. This is an error that is due to the 
HOST-CTAS patch. This error must be removed eventually. Such errors have been observed in 
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Figure 6. Aircraft tracks with large jumps. 


most of the data files obtained from Denver Center. This error is not observed in the ASP system, 
where it would affect the undelayedJMFT calculations. How this affects CTAS scheduling will be 
shown next. 

The effect of these trajectory jumping errors on scheduling is seen in figure 8 for both of the 
aircraft of figures 6 and 7. ETAs are shown as thin solid lines, and STAs are shown as dots 
connected by thin lines. ETA and STA change as the incorrect track departs from the flight plan 
route. When the proper aircraft data are acquired, the ETA and STA settle to the correct value. The 
curves were chosen to be labeled using the ‘On Track' selection which labels the end of the curves 
with aircraft ID, aircraft type, error between actual crossing of the feeder fix and the displayed 
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Figure 7. Altitude tracks for the aircraft in the last figure (individual data points shown). 


value, and the gate number, which agrees with that shown in the x/y plot. Both aircraft were 
finally scheduled to runway 26R. 

Figure 9 shows the effect of scheduling the aircraft to the runway. While the final selection is not 
affected, schedules are upset because of the two aircraft trajectories shown in figures 6 and 7. 
There are also partial curves shown in figure 9. This is the effect of runway optimization, where 
26R was considered for other aircraft before the freeze horizon. 


28 







In both figures 8 and 9 data are shown only when the aircraft is ‘active’, that is, radar data are 
available. When only the flight plan is available, ETAs and STAs are calculated based on the 
coordination fix estimated time of arrival plus CTAS calculated time from the coordination fix to 
the runway threshold. More recently, STA data are also recorded based on the coordination fix 
times in the flight plans, which are later replaced by computations based on radar and other data. 

Figure 10 shows vertical trajectories for one-half hour of traffic using large unconnected data 
points for plotting. It will be noted that there are no data at certain times, which are supposed to be 
12 seconds apart. This is thought to be caused by a CTAS synchronization problem but does not 
affect the operation of the system. This problem must eventually be fixed. 



Figure 10. Missing radar data. 
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Figure 11. Radar determined trajectory jumps close to touchdown. 


Figure 11 shows some examples of spurious radar data after the aircraft have landed. By choosing 
‘show ACID?: top/side’, for the x/y plot, the aircraft IDs are listed in the quadrant that each 
aircraft track originates. These and the next aircraft trajectories have been obtained by perusing 
the jump_xy_ file. Since Center radar data are primarily useful in the Center, errors shown in 
figure 11 are of no consequence. 
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Figure 12.1 shows several flightpaths, which have missing radar hits. Thin lines connect the heavy 
data points, thereby showing the flightpath and flightpath segments without radar data. If no 
special measures are taken, these missing data points can lead to CTAS errors. These aircraft were 
also listed in the jump_xy file. 

The feeder fix selection capability of AN permits one to determine if the incorrect feeder fix was 
selected from the flight plan by CTAS or if gate balancing occurred and was not entered into the 
system. To distinguish between the two possibilities one has to examine the flight plan, which is 
recorded in the cm data file, after one has identified the aircraft ID. After a few trial selections 
using ‘ACID Incl:’ and ‘ACID Excl:’ one can find the specific aircraft that flew across a diff erent 
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Figure 12.2. First step in finding gate assignment errors. 

gate or feeder fix from that assumed by CTAS (fig. 12.2). If it is a problem with flight plan 
interpretation, the programmer concerned with such matters is notified to correct the error. 

It is now time to review some of the overview data plots that are available. 







Figure 13. Traffic throughput through the feeder fixes plus arrivals at the individual feederfixes. 


Figure 13 shows the number of aircraft flying across the feeder fixes per hour. This is determined 
by counting the number of aircraft in a one half hour interval and multiplying by two. The 
resulting data point is plotted at the center of the half hour interval. The interval is then shifted by 
10 minutes and the process repeats. Figure 13 shows two rush periods separated by one hour. The 
four sets of short vertical lines indicate the times when each aircraft crosses a specific feeder fix. 
Only the four main feeder fixes are shown in the lower part of the figure, which indicates how 
rushes develop from different directions. No effort is made to prevent lines from superimposing. 



Figure 14. Landing throughput for all aircraft and all runways. 

Figure 14 is constructed in a manner similar to figure 13, except that now the landing aircraft are 
counted. The figure is for the same data sample as figure 13. It essentially shows a time shift due 
to the time that passes between entering the TRACON and landing. Only totals are shown, since 
the Center Radar is not accurate enough to determine a runway of a pair of closely spaced parallel 
runways. 
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Figure 15. Time lines of radar coverage for all aircraft. 


Figure 15 shows for each aircraft the time range that it is in Center radar coverage in the Center 
and in the TRACON areas. A count of the aircraft along each vertical line gives the number of 
arriving aircraft in the Center and TRACON. Departing aircraft are not accounted for, since such 
information is not transmitted by the Host to CTAS. 
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Figure 16. Scheduled delays and number of scheduled aircraft vs. time. 

Figure 16 shows the total scheduled delays versus time as well as the number of aircraft that were 
in the Center, which were scheduled. Scheduled delays are correlated with the number of aircraft 
presently in the Center. But the total scheduled delay also depends on the runway configuration, 
runways acceptance rate, and on the ETA bunching of the aircraft. 










Figure 17.1. MFT order deviation. 


Figures 17.1 and 17.2 show for each feeder fix the deviation of the order from the actual order in 
which the aircraft cross the feeder fix and the order that was predicted by the quantity selected. In 
this case, in figure 17.1, MFT (the ASP predicted metering fix crossing time) is shown. These are 
the times that the sector controllers try to meet, when metering is used. Figure 17.2 shows the 
ETAs for the same case. As is usually the case, the ETAs are a better indicator of aircraft order 
than the MFT, in spite of the fact that CTAS is not controlling the traffic. The data are shown for 
the estimates that are recorded when the individual ETAs indicate a specific time to the feeder fix, 
in this case 19 minutes. 
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Figure 17.2. ETA_ff order deviation. 

The same data can also be displayed in a more quantitative way (fig. 17 .3), where ETA_ff error is 
plotted versus the actual crossing time. Here one can select different times when the estimate is 
displayed e.g., ETA_ff = 19 minutes. The ETA_ff = 0 minutes is useful to discover when the 
ETA_ff calculation was made to the wrong feeder fix. The calculation of the actual feeder fix 
crossing is made from radar data and registers the crossing when any of the feeder fixes is 
overflown within a reasonable distance. When ETA_ff registers about 10 minutes early, that 
means that a feeder fix was flown over, but the incorrect feeder fix to which the ETA_ff was 
calculated is still a distance away. This was the case for aircraft AAL1636. When the traffic is not 
heavy, or when there are segments of light traffic a similar figure can be drawn for other predicted 
times to a feeder fix, and one can compare the simpler estimation of time to feeder fix with the 
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more elaborate method that CTAS is using. Both sets of data can be plotted simultaneously 
(fig. 17.4), where the dot denotes CTAS data and the other end of the line denotes ASP data, 
which are both recorded when CTAS predicts a specific time to go to the feeder fix. It will be 
noticed that the CTAS data are usually more accurate. 


40 





Figure 17.4. ETA_ff and undelayed MFT vs feeder fix overcrossing time. 






Figures 18.1 and 18.2 show comb diagrams for the ASP and CTAS systems respectively. The 
three values plotted for each aircraft, connected by straight lines, show VTAff, MFT, and actual 
crossing time of the feeder fix for ASP in figure 18.1, and the equivalent values for CTAS in 
figure 18.2. The estimated and scheduled values are shown for each aircraft when ETA_ff for that 
aircraft is 19 minutes, which is shortly after freezing the schedule. The MFT and STA values do 
not form a schedule in the sense that a schedule consists of a set of estimated arrival times and 
corresponding scheduled arrival times, all calculated at the same time. 

Recent experimentation with the CTAS scheduler has improved the schedule, so that comb 
diagrams are more consistent as one would expect from a good scheduler. One must remember 
here that these data are from live data recording where ASP is in control and not CTAS. 
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Figure 18.2. Feeder fix comb diagram for CTAS. 


It should be clear that figures 18.1 and 18.2 are not really schedules. They would have been 
schedules if etas and eta_ff were time independent. A schedule, however, is formed from etas and 
it has to meet constraints at each specific time. These are the data that must be checked against the 
constraints which are present to see if they are proper schedules. 

Figure 19.1 shows a feeder fix schedule and figure 19.2 shows a runway schedule. The runways 
are relatively well balanced in spite of the fact that all northern traffic was scheduled to 26R 
(except for the heavies, which were scheduled to 26L) and all southern traffic was scheduled to 
26L. Each aircraft has been labeled to give a maximum amount of information. The type (jet, 
turboprop, or prop) is given followed by its class (heavy, large, or small). In addition we give 





Figure 19.1. Feeder fix schedule. 


information if the aircraft is radar tracked (active) and whether the schedule for the given aircraft 
is frozen or not. This is true for both snapshot figures. CTAS for these figures still used the old 
scheduler, which depended on oetas for sequencing. As can be seen for this example there are 
several questionable sets of data where lines cross. (See, e.g., MRK7471 scheduled for 26L.) 
Careful examination of other data indicated that ETAs were not updated for some reason in spite 
of the fact that radar data were available. 
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The Distance from Airport versus Time Plot. This plot is of importance to monitor how traffic 
controllers actually manage traffic. As will be seen from the following example, they manage 
traffic by managing distance separations, and very seldom is there any change in distance order. 
This has important implications on how to design a scheduler, which is easy to use by a 
controller. Figure 20 shows the traffic through the feeder fix ACTON (DFW), where most of the 
southern traffic through ACTON has been removed. Figure 21 shows the accompanying distan ce 
vs. time plot for the same aircraft. An apparent conflict of DAL282 with AAL1074 is not actually 
a conflict, since the aircraft are on different routes (S-N vs. W-E). At the critical moment before 
crossing the feeder fix AAL1074 was delayed for proper separation. 

V-2 Selecting Specific Curve(s) From a Group of Curves. Often, when a large group of curves 
is plotted, one notices a curve that is out of the ordinary for some reason or other. Even though the 
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curve may be labeled, because of the density of the curves, the labeling may not be clear or may 
be overwritten. The jumpjiles were originally created to aid in this problem for the slow original 
AN program. They are still helpful, especially when the problems are not very apparent on the 
graph. This is the case when, for example, there are missing radar data for an aircraft track. The 
jump_xy file lists all aircraft with larger data gaps. Using the AC ID Incl: filter button one can 
examine several aircraft listed in the jump_xy file at a time. Just recently it was discovered that 
when radar data for a particular aircraft were missing beyond a certain length of time, the aircraft 
was dropped from the schedules, and, when the track data reappeared, scheduling problems arose. 
For discovering other problems, due to AN’s high speed of replotting, it is often sufficient to thin 
the number of curves by selecting one or more of the filtering buttons until the curve of interest is 
not eliminated and the labeling is separated enough to identify the curve. 



Figure 21. Distance to airport vs. time for flightpaths shown in figure 20. 
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V.3 Rerunning the Data. As ATC system, CTAS must operate with live data in real time. 
However, for design checkout purposes, two other modes of operation exist. As second mode of 
operating, CTAS works with simulated data (pseudo aircraft flown by pseudo pilots). As third 
mode of operation, CTAS works in the playback mode, where recorded live data are used to 
provide input radar data as well as certain ASP data to the system, and CTAS will generate a new 
data tape. There are several advantages of this third mode of operation. One, the input data 
contains the actual radar noise, and the aircraft trajectories are realistic for the traffic situation. 
Two, in the replay mode one can know in advance about runway changes, aircraft departing local 
airports, gate balancing decisions and other TMU decisions, and one can enter them into CTAS in 
a shadow mode. Three, the type of traffic can be chosen in advance by selecting traffic samples 
from a library. Four, the traffic can be simplified by selecting and eliminating certain aircraft from 
the file, which present special problems that are presently not of interest. One such problem is 
presented by an aircraft which appears twice in the data base and actually represents one 
departing and, at a different time, a different approaching airplane. 

The operation of the playback mode in the shadow mode would take an experienced TMU. This is 
presently not done for lack of personnel. Instead, a passive playback mode of operation is used, 
which permits testing and comparing of different scheduling functions as well as other tests 
without human intervention in the TMA. Of course, the difficulty with both modes of operation is 
that CTAS does not control the traffic, but CTAS computes ETAs and STAs as if it were to control 
traffic. By knowing in advance what the actual traffic will look like in the future (e.g. runway 
changes and gate balancing), some adjustments can be made to CTAS to take these events into 
account. 

V.4 Results Cross Checking With the cm File or Results not explored in AN. In order to check 
results with the original data file, one has to become familiar with the cm file. Following are some 
of the more common record types. The first capitalized word is the identifier, which is easy to 
read. The second number means the same but is more quickly interpreted by the computer. This is 
followed by the data, which are given in the same order as in table 1. Here are some of the most 
important examples, where the meaning of the data entries can be obtained from table 1. 
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START_TIME 101 752809914.841 


AC_DATA 1 440 ASH7549 400.000 322.875 23000 280 42 0 2 428.05 2801 

ADD FLIGHTPLAN 10 223 COA1550 B727 2 SIX J56.DEN .DEN/1 750 SLC SLC078120 -1162 248.1 447.4 37000 452 -9999800 DFN 9999999 542 572 T/B727/ 
AESTIMATEDFPr 

DELETEFLIGHT PLAN 31 COA1550 

A SSIGN^ RUNWAY 20 223 ASH7789 10 00 

RECORD DATA 73 301 TM MSG TIM ASH7549 BF02 BYSON 752810216 752812165 752812107 752812107 752811109 752811016 75281 1016 752810764 
752810860 1 5 

A ECORD.DATA 73 524 TM MSG FIX: CO A 1214 0 DRAKO 752810425 0.59 98.35 432.75 421.12 413.96 21500.00 752810125 -300 -00:05:00 

The records are long and not easy to read. A few UNIX commands combined in a shellscript can 
often isolate the data of interest. Shellscripts are used for rapid prototyping, or when the 
examination applies to a few cases. A few of the shellscripts are given below to show their 
compactness. When the specific investigation is to be repeated for all future files, a C-program is 
written and incorporated into the AN program. The simplest example is when all data for a 
specific aircraft are required. Typing: grep ACID file name > output Jile name is all that is 
required, where ACID is the aircraft identifier. From table 1 it will be noted that oETA is not 
plotted. By replacing ETA with oETA and STA with ETA, which is a one line ‘AWK’ program, 
one can alter the file: 


awk ‘ { if ($5 ~/TIM/) 

{print$l,$2,$3,$4,$5,$6,$7,$8,$9,$ll,$10,$ll,$14,$13,$14,$16,$17,$18,$19} else print}’ $1 > 

$2 
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VI. Final Comments 


One of the advantages that showed up clearly in the early analysis of CTAS data was that the 
precisely calculated ETAs using fiightpaths determined from the flight plan, using aircraft lift, 
drag and thrust models for the aircraft type specified in the flight plan, and using a detailed wind 
model produced an estimation of the order of arrival at the feeder gates, which reflected the actual 
order of arrival much better than even the MFTs which the controllers attempt to follow. This 
makes it likely that a scheduler which primarily schedules according to first come first served 
order will result in an efficient and controller-acceptable system. 

Many additions were made to the AN program when emphasis was shifted from obtaining good 
ETAs to good schedules. Still, it is quite a different matter when analyzing traffic that is not 
controlled, to traffic that is controlled by CTAS. One of the differences that immediately showed 
up when analyzing simulation data for the new Denver airport was that when analyzing live ASP 
controlled traffic, the plot of STA_ff - ETA_ff began when the aircraft was radar tracked and 
ended when the schedule was frozen. This permitted checking that STA_ff - ETA_ff remained 
positive at all times, except for the limited time advance. After freeze STA_ff and ETA_ff had no 
relation, since the aircraft were not controlled by CTAS. However, when CTAS does control the 
traffic, which is presently only done in simulation, one is very much interested in the quantity 
STA_ff - ETA_ff from schedule freeze to actual feeder fix crossing, since this quantity should 
reduce and go to a small value for each aircraft as it crosses the feeder fix. 

AN has been extensively tested and developed for the Denver Center. As AN is adapted to other 
airports and TRACONs as well as Centers, many other changes are expected to be made to track 
the development of CTAS and contribute to its smooth operation. One example of additions being 
made, is calculating and presenting separation distances at the feeder fixes and runway thresholds. 

All future changes to the AN program will be documented separately. 
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